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DETAILED ACTION 



2 



3 



All objections and rejections not set forth below have been withdrawn. 



4 
5 
6 



Claims 1 -3, 6-8, 10-13, 16 - 18, 22, and 23 are pending. 



7 



8 



Drawings 



9 



10 



The drawings are objected to under 37 CFR 1 .83(a). The drawings must show 



1 1 every feature of the invention specified in the claims. Therefore, the claimed features 

12 (e.g. packets having state information for address translator processing, means for 

13 adding state information to packets, means for adding separate User Datagram Protocol 

14 headers to packets) must be shown or the feature(s) canceled from the claim(s). No 

15 new matter should be entered . 

16 Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in 

17 reply to the Office action to avoid abandonment of the application. Any amended 

18 replacement drawing sheet should include all of the figures appearing on the immediate 

19 prior version of the sheet, even if only one figure is being amended. The figure or figure 

20 number of an amended drawing should not be labeled as "amended." If a drawing figure 

21 is to be canceled, the appropriate figure must be removed from the replacement sheet, 

22 and where necessary, the remaining figures must be renumbered and appropriate 

23 changes made to the brief description of the several views of the drawings for 
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1 consistency. Additional replacement sheets may be necessary to show the renumbering 

2 of the remaining figures. Each drawing sheet submitted after the filing date of an 

3 application must be labeled in the top margin as either "Replacement Sheet" or "New 

4 Sheet" pursuant to 37 CFR 1.121 (d). If the changes are not accepted by the examiner, 

5 the applicant will be notified and informed of any required corrective action in the next 

6 Office action. The objection to the drawings will not be held in abeyance. 
7 

8 

9 Specification 

10 

1 1 The specification is objected to as failing to provide proper antecedent basis for 

1 2 the claimed subject matter. See 37 CFR 1 .75(d)(1 ) and MPEP § 608.01 (o). Correction 

13 of the following is required: Claim 3 comprises the limitation "wherein the fragmenter 

1 4 module does not split the IKE data packets unless no response to a previously-sent IKE 

15 data packet has been received". The Applicant has not pointed out where the amended 

1 6 claim is supported, nor does there appear to be a written description of the claim 

17 limitation in the application as filed. 



18 

1 9 Claim Rejections - 35 USC §112 

20 

21 The following is a quotation of the first paragraph of 35 U.S. C. 112: 

22 The specification shall contain a written description of the invention, and of the manner and process of 

23 making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the 
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1 art to which it pertains, or with which it is most nearly connected, to make and use the same and shall 

2 set forth the best mode contemplated by the inventor of carrying out his invention. 
3 

4 Claim 3 is rejected under 35 U.S.C. 112, first paragraph, as failing to comply 

5 with the written description requirement. The claim contains subject matter 

6 which was not described in the specification in such a way as to reasonably 

7 convey to one skilled in the relevant art that the inventor(s), at the time the 

8 application was filed, had possession of the claimed invention. See above 

9 objection to the specification. 
10 



1 1 The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

1 2 The specification shall conclude with one or more claims particularly pointing out and distinctly 

1 3 claiming the subject matter which the applicant regards as his invention. 
14 

15 Claims 1, 2, and 18 are rejected under 35 U.S.C. 112, second paragraph, as 

16 being indefinite for failing to particularly point out and distinctly claim the subject 

17 matter which applicant regards as the invention. 

18 Specifically the recitation "in response to receiving ... determining that IKE 



19 fragmentation is capable" is nonsensical. The examiner notes that no presumption is 

20 made by the examiner nor by the applicant for "IKE fragmentation" itself to be capable 

21 (i.e. possess the ability) of anything. For the purpose of examination, the examiner 

22 presumes the applicant to recite "determining the IKE fragmentation capabilities of a 

23 receiving node by reference to the vendor identification value" as is found disclosed 

24 within the applicant's specification, pg. 20, lines 14-20. 
25 

26 
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1 Claim Rejections - 35 USC § 103 

2 

3 The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 

4 obviousness rejections set forth in this Office action: 

5 (a) A patent may not be obtained though the invention is not identically disclosed or described as set 

6 forth in section 102 of this title, if the differences between the subject matter sought to be patented and 

7 the prior art are such that the subject matter as a whole would have been obvious at the time the 

8 invention was made to a person having ordinary skill in the art to which said subject matter pertains. 

9 Patentability shall not be negatived by the manner in which the invention was made. 
10 

1 1 Claims 3,6-8,10-13, 16 are rejected under 35 U.S.C. 103(a) as being 



12 unpatentable over Thread Topic (TT), "RE: CERT REQ PAYLOAD usage", in view 

1 3 of Jinmei, "How to write UDP/lpv6 applications that care about path MTU", in view 

14 of Kent et al. (Kent), "Fragmentation Considered Harmful". 

15 

1 6 Regarding claim 3, TT discloses the generating and transmitting an IKE packet 

17 over a network (TT, pg. 1 , par. 1-3). TT discloses that the problems with unintentional 

18 fragmentation occur when IKE payloads are encapsulated within singular, large UDP 

19 packets, which can be subsequently fragmented (TT, pg. 1-2, par. 7). TT teaches to 

20 avoid fragmented IKE payloads and suggests for IKE applications to incorporate path 

21 discovery so as to reduce the size of IKE payloads that will be encapsulated within UDP 

22 packets (TT, pg. 4, par. 1-4; pg. 7). 

23 TT does not appear to explicitly state that, an IKE application, as a result of 

24 discovering the MTU, should fragment a packet into a plurality of packets, i.e. 

25 fragmenting the IKE packet into a plurality of smaller packets and transmitting each of 

26 the plurality of smaller packets over a network. 
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1 However, Jinmei teaches that an application, such as IKE, can discover the path 

2 MTU and subsequently avoid fragmentation by dividing a single packet into a plurality of 

3 smaller packets (pg. 2, 3). It would have been obvious to one of ordinary skill in the art 

4 to recognize teachings of Jinmei along with the teachings of TT. This would have been 

5 obvious because one of ordinary skill in the art would have been motivated to 

6 implement a mechanism so as to avoid unintentional fragmentation. 

7 The combination enables fragmenting IKE packets according to an appropriate 

8 before creating or encapsulating the packets as IKE payloads within UDP. However, 

9 IPSEC does not appear to specifically state known methods of packet fragmentation, 

10 such as conditions requiring fragmentation and that a packet fragment should have a 

1 1 proper packet header. 

12 Kent et al. discloses principles for packet fragmentation. While Kent discusses 

13 these principals of packet fragmentation often in the context of the IP layer (Kent, pg. 

14 75, par. 4), Kent further discloses that these fragmentation methods are to be applied in 

15 higher protocol layers as well. Upper level protocol layers should be cognizant of 

16 fragmentation issues, and should fragment or send smaller packet sizes if it is known 

17 that a larger packet size will be fragmented at the IP layer (Kent et al., section 3, par. 4). 

18 For example, Kent discloses that an upper layer (i.e. TCP) should not send a large un- 

19 fragmented segment when it a lower layer (i.e. IP) will have to fragment it (Kent, pg. 79, 

20 pars. 3, 4). Kent discloses that the packet fragmentation method consists of 

21 fragmenting a larger packet into a plurality of fragments. Each fragment is sent as a 

22 separate packet, with each of the plurality of smaller packets containing a properly 



Application/Control Number: 10/056,889 Page 7 

Art Unit: 2137 

1 formatted header according to the protocol (Kent et al., section 2.1 ). It would have been 

2 obvious to one of ordinary skill in the art to employ the principles for packet 

3 fragmentation disclosed by Kent with the teachings of the combination of TT and Jinmei 

4 requiring the fragmentation of IKE packets. This would have been obvious because one 

5 of ordinary skill in the art would have been motivated to practically implement packet 

6 fragmentation methods for the purpose of fragmenting IKE packets so as to avoid 

7 creating large UDP packets as taught by the combination of TT and Jinmei. 



8 Therefore, the combination enables: 

9 a User Datagram Protocol (UDP) stack that is capable of generating UDP data 

1 0 packets for transmission over a network (TT, pg. 1 -2, par. 7; pg. 4, par. 1 -6). 

1 1 an IKE protocol stack that generates IKE data packets that are subsequently 

12 processed by the UDP protocol stack (TT, pg. 7; pg. 1-2, par. 7; Jinmei, pg. 2); 

1 3 and a fragmenter module that intercepts IKE data packets prior to being 



1 4 processed by to the UDP protocol stack and splits the IKE data packets into a plurality 

1 5 of smaller data packets that may be subsequently formatted by the UDP protocol stack 

16 (TT, pg. 7; Jinmei, pg. 2). The combination enables fragmenting IKE packets (thus a 

17 fragmenter module) prior to being processed by the UDP stack. 

1 8 wherein the fragmenter module does not split the IKE data packets unless no 

1 9 response to a previously-sent IKE data packet has been received (Kent et al., section 

20 3.3, pars. 1 - 3). Herein, the combination enables that once a suitable response is 

21 received, the fragmenter module does not continue to split the data packets. 
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1 and wherein, each of the plurality of smaller data packets includes a header 

2 formatted according to the IKE protocol and state information for network address 

3 translator processing (Kent, sect. 2.1 , par. 1 — herein the prior art discloses that each 

4 fragment is sent as a separate packet, with each of the plurality of smaller packets 

5 containing a properly formatted header according to the protocol). 
6 



7 Regarding claim 6, it is rejected, at least for the same reasons as claim 3, and 

8 furthermore because the combination enables: 

9 sending a vendor identification value, the vendor identification value indicating 

10 IKE fragmentation capability (TT, pg. 7 - the prior art discloses using the IKE protocol, 

1 1 thus the sending of a vendor identification value as established by the protocol), 

1 2 receiving a plurality of fragments of an IKE data packet from a transmitting node, 



1 3 wherein each fragment includes an identifier that associates each fragment with an IKE 

1 4 data packet ; and discarding all fragments that contain a first identifier if a 

1 5 predetermined number of fragments are received that contain a second identifier (Kent 

16 et al., section 2.4, par. 3); 

17 and determining the total size of all fragments that contain the same identifier 

18 and discarding said fragments when the total size exceeds a predetermined limit (Kent 

19 et al., section 2.4, par. 2, 3). Herein, the combination discloses that a fragment 

20 reassembly process may not progress if the total size of a datagram (comprising 

21 fragments with a same identifier) exceeds a predetermined limit. As an example, a 

22 sufficiently sized space for reassembling a large datagram could comprise a size of 8 
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1 buffer spaces. Thus, when that predetermined limit is achieved, the occupying 

2 fragments of an unassembled datagram will expire and be discarded. 
3 

4 Regarding claim 7, the combination of enables: 

5 wherein the step of discarding all fragments that contain a first identifier is 

6 performed when at least one fragment is received that contains a second identifier (Kent 

7 et al., section 2.4, par. 3). 
8 

9 Regarding claim 8, the combination enables: 

1 0 determining whether all fragments that are associated with an IKE data packet 



1 1 have been received, and sending a no acknowledgment (NAK) message to the 

1 2 transmitting node when at least one fragment has not been received (Kent et al., section 

13 3.3.3). A receiving host is disclosed as making a determination as to whether all 

14 fragments associated with an IKE packet has been received. The receiving host will 

15 convey a "Time exceeded" message ("NAK") to the transmitting host when at least one 

16 fragment has not arrived, indicating to the transmitting host that it has not received all 

17 the fragments. 
18 

19 Regarding claim 10, the combination does not appear to explicitly state wherein 

20 the predetermined limit is 64 kilobytes. This, however, would have been obvious to one 

21 of ordinary skill in the art to set a predetermined limit of 64 kilobytes as the total size of 

22 all possible fragments. As evidenced by the "Glossary for the Linux FreeS/WAN 
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1 project" - (definition for DoS), this would have been obvious to one of ordinary skill in 

2 the art because the standardized size limit of an IP packet is 64 kilobytes, and a failure 

3 to discard illegitimate packets when the size exceeds the standard limit would result in 

4 denial of service attacks. 
5 

6 Regarding claim 1 1 , it is rejected, at least, for the same reasons provided for the 

7 rejection of claim 3, and furthermore because the combination discloses that to avoid 

8 unnecessary fragmentation of packets (Kent, section 3.2), the system should be 

9 cognizant of network timing issues. Thus, a system will not assume it is necessary to 

10 retransmit a packet until a determined period of time ("round-trip time" or the estimated 

1 1 time period between a sender's packet transmission and a sender's reception of a 

1 2 packet acknowledgement response)(Kent, section 3.2.1 ). 

13 While the combination does not nominally recite "a timer", it would have been 

14 obvious to one of ordinary skill in the art to employ appropriate timing means ("a timer") 

15 for determining when packet retransmission is necessary. This would have been 

1 6 obvious because one of ordinary skill in art would have been motivated by the 

17 combination's teachings for measuring and determining timing delays before 

18 retransmitting previously transmitted packets within a system. 

19 Additionally, the combination discloses the encapsulation of IKE packet 

20 fragments and their transmission through underlying protocols such as UDP. Therefore, 

21 the combination enables for IKE and UDP headers for the transmitted packets. 
22 
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1 Regarding claim 12, the combination enables: 

2 further comprising means for determining the capability of the receiver node for 

3 receiving fragmented packets (Kent et al., section 3.3, par. 2). 
4 

5 Regarding claims 13, it is rejected, at least, for the same reasons as claim 3 and 

6 11. 
7 

8 Regarding claim 16, the combination enables: 

9 wherein the plurality of smaller packets contain the same information as that 
10 contained within the original IKE packet (Kent et al., section 2.4, par. 3, section 2.1 ). 
11 

12 Regarding claim 20, it is rejected, at least, for the same reasons as claims 1 and 

13 11, and further because the combination enables: 

1 4 fragmenting the packet into a plurality of fragments using a code module that 



1 5 does not implement the TCP, UDP or IP protocols before the packet is processed by a 

1 6 code module that does implement the TCP, UDP or IP protocols (Jinmei, pg. 2; TT, pg. 

17 7; Kent et al., section 3). The combination enables fragmentation which is application 

18 based and therefore inherently performed by some type of module for instructing a 

19 computer ("code module"). 

20 comprising including an identifier that identifies the data packet in each packet 

21 fragment (see rejection of claim 2); and transmitting the packet fragments over a 

22 network (see rejection of claim 1 ). 
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1 

2 Claims 22 - 23 are rejected under 35 U.S.C. 103(a) as being unpatentable 

3 over the combination of TT, Jinmei, and Kent in view of Cerf et al. (Cerf), "A 

4 Protocol for Packet Network Intercommunication". 

5 

6 Regarding claim 22, it is rejected, at least, for the same reasons as claims 3 and 

7 6, and furthermore because the combination enables: 

8 receiving a plurality of fragments of a single IKE data packet, wherein the 

9 fragments were transmitted from a transmitting node in an order that can be determined 

1 0 from information contained within the received data fragments (Kent et al.; section 2.1 , 

1 1 par. 3; section 2.4, par. 3). The combination does not disclose that a receiver may 

12 detect duplicate packets from a single IKE packet and then discard such duplicates. 

13 Cerf discloses that a receiver which receives duplicate packets will discard such 

14 duplicates. Additionally, Cerf discloses that a receiver may detect out of order packets, 

15 and choose to store and acknowledge such packets or discard such packets (Cerf, pg. 

16 7-8, "Retransmission and Duplicate Detection"). It would have been obvious to one of 

17 ordinary skill in the art to detect and discard duplicate packets. This would have been 

1 8 obvious because one of ordinary skill in the art would have been motivated to avoid 

19 resource consummation by superfluous data. 
20 
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1 Regarding claim 23, the combination discloses sending a message to the 

2 transmitting node that out of order packets have been received (Cerf, pg . 7-8, 

3 "Retransmission and Duplicate Detection"). 
4 

5 Response to Arguments 

6 

7 Applicant's arguments filed 1/23/08 have been fully considered but they are not 

8 persuasive. 
9 

1 0 Applicant argues essentially that: 
11 

1 2 (i) The recitation "wherein the fragmenter module does not split the IKE data 

13 packets unless no response to a previously-sent IKE data packet has been received' is 

14 supported by the original disclosure. (Remarks, pg. 9) 
15 

1 6 Specifically, applicant asserts that the recitation "wherein the fragmenter 

17 module does not split the IKE data packets unless no response to a previously-sent IKE 

18 data packet has been received' is supported by the original disclosure. However, the 

1 9 examiner points out that the applicant has not shown support for the recitation of not 

20 splitting IKE packets unless no response is received, nor does there appear to be a 

21 written description of the claim limitation in the application as filed. Specifically, while 

22 the applicant points to support for the concept of not fragmenting when packets are 
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1 successfully transmitted, the examiner notes that the applicant fails to show the concept 

2 of never fragmenting unless there is no response received. 
3 

4 (ii) Prior art does not teach the inclusion of state information within the transmitted 

5 IKE packets, such as may be found recited within claim 3. (Remarks, pg. 11). 
6 

7 In response, the examiner respectfully notes that the prior art enables for packets 

8 to comprise state information that permits processing by network elements such as 

9 NATs (Kent, sect. 2.1) 
10 

1 1 (iii) Prior art does not teach "sending a vendor identification value, the vendor 

12 identification value indicating IKE fragmentation capability", such as may be found 

13 recited within claim 6. (Remarks, pg. 11) 
14 

15 In response, the examiner respectfully notes that the prior art discloses 

16 communication according to the IKE protocol. As transmitting packets comprising 

17 vendor identification values are characteristic of the IKE protocol, the examiner notes 

18 that the prior art enables for sending of a vendor identification value". Furthermore, it is 

19 noted regarding the recitation of the intended use of a transmitted vendor identification 

20 (e.g. indicating IKE fragmentation capability) that the claim's characterization of a 

21 vendor identification value does not result in novelty over the prior art's vendor 

22 identification value. 
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1 

2 Conclusion 

3 

4 The prior art made of record and not relied upon is considered pertinent to 

5 applicant's disclosure. 
6 

7 See Notice of References Cited 

8 

9 Applicant's amendment necessitated the new ground(s) of rejection presented in 

10 this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP 

1 1 § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 

12 CFR 1.136(a). 

13 A shortened statutory period for reply to this final action is set to expire THREE 



14 MONTHS from the mailing date of this action. In the event a first reply is filed within 

15 TWO MONTHS of the mailing date of this final action and the advisory action is not 

1 6 mailed until after the end of the THREE-MONTH shortened statutory period, then the 

17 shortened statutory period will expire on the date the advisory action is mailed, and any 

18 extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of 

19 the advisory action. In no event, however, will the statutory period for reply expire later 

20 than SIX MONTHS from the date of this final action. 

21 Any inquiry concerning this communication or earlier communications from the 

22 examiner should be directed to Jeffery Williams whose telephone number is (571 ) 272- 

23 7965. The examiner can normally be reached on 8:30-5:00. 
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1 If attempts to reach the examiner by telephone are unsuccessful, the examiner's 

2 supervisor, Emmanuel Moise can be reached on (571 ) 272-3865. The fax phone 

3 number for the organization where this application or proceeding is assigned is (703) 

4 872-9306. 

5 Information regarding the status of an application may be obtained from the 

6 Patent Application Information Retrieval (PAIR) system. Status information for 

7 published applications may be obtained from either Private PAIR or Public PAIR. 

8 Status information for unpublished applications is available through Private PAIR only. 

9 For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 

10 you have questions on access to the Private PAIR system, contact the Electronic 

1 1 Business Center (EBC) at 866-21 7-91 97 (toll-free). 
12 

13 

14 J.Williams 

15 AU2137 
16 

17 /Emmanuel L. Moise/ 

18 Supervisory Patent Examiner, Art Unit 2137 
19 

20 
21 

22 



